Method and system for masking data

ABSTRACT

An approach is provided for masking data. A determination is made whether an action initiated by an authenticated user corresponds to one of a plurality of policies stored in a policy store, wherein the policies relate to whether data to be retrieved from a data source is to be masked. A new policy is generated if no match is found in the policy store. Information associated with the new policy is received, wherein the information is input by the user. The new policy is stored in the policy store.

BACKGROUND OF THE INVENTION

Globalization and innovations in communication systems have changed themanner in which society lives, does work, etc. Information technologicalrevolutions, such as the Internet, have created a virtual world withoutboundaries; such exemplars include virtual offices, virtual businesses,virtual hospitals, and online trading. Moreover, modem informationtechnology (IT) operations and IT enabled services can become virtual interms of off shoring and near shoring. Data management and protectionplay a key role in advancing these services. It is recognized that whilein transit from one physical location to another, personal, business, orgovermmental sensitive data need to be protected.

In fact, data protection is necessary to ensure compliance with variousprivacy laws mandated by numerous countries. For example, in manyjurisdictions, sensitive data is not permitted to enter foreign land.Consequently, data that crosses a foreign boundary needs to bede-personalized or sanitized. De-personalization, if performedeffectively, can stimulate more offshore work.

Conventionally, cryptography has been utilized to ensure dataprotection. Even though classical cryptographic techniques address theconcerns of privacy when data is in transit, such techniques do noteffectively resolve the handling of data after its decryption. Inaddition, it is difficult to implement total communication security;such approach is not only costly, but key management is tedious.Further, because data can be accessed through any application (whichprotects user level authorization), the data can be inadvertentlydisclosed to an unauthorized end user.

Therefore, there is a need for an approach for de-personalizing data asto accommodate a wide range of applications.

BRIEF DESCRIPTION OF THE DRAWINGS

Various exemplary embodiments are illustrated by way of example, and notby way of limitation, in the figures of the accompanying drawings inwhich like reference numerals refer to similar elements and in which:

FIG. 1 is a diagram of a system capable of providing data masking,according to an exemplary embodiment;

FIG. 2 is a flowchart of an overall data masking process, according toan exemplary embodiment;

FIGS. 3A and 3B are, respectively, a diagram of a masking configurationwizard application of the system of FIG. 1, and a flowchart of aconfiguration process, according to various exemplary embodiments;

FIGS. 4A and 4B are, respectively, a diagram of a data masking proxy ofthe system of FIG. 1, and a flowchart of a data masking engine process,according to an exemplary embodiment;

FIG. 5 is a diagram of a masking algorithm engine of the system of FIG.1, according to an exemplary embodiment;

FIG. 6 is a circuit diagram showing overall data masking process asthreaded model, according to an exemplary embodiment; and

FIG. 7 is a diagram of a computer system that can be used to implementvarious exemplary embodiments.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

A system, method, and software for masking data are described. In thefollowing description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It is apparent, however, to oneskilled in the art that the various exemplary embodiments may bepracticed without these specific details or with an equivalentarrangement. In other instances, well-known structures and devices areshown in block diagram form in order to avoid unnecessarily obscuringthe exemplary embodiments.

Although the various exemplary embodiments are described with respect todata masking, it is contemplated that these embodiments haveapplicability to any mechanisms that de-personalizes data.

FIG. 1 is a diagram of a system capable of providing data masking,according to an exemplary embodiment. A data masking architecture isshown in which a data source 100 supplies data to a data destination110. By way of example, the data source 100 may be a database or file.Also, the data destination 110 can be a database, a file, anapplication, a browser, a proxy, or a client application. Whenever thedata from the data source 100 is accessed by the data destination 110,the data is de-personalized (or sanitized).

According to one embodiment, the data masking architecture includes adata masking proxy 120, a data masking configuration wizard 130, apolicy store 140, a masking algorithm engine 150, a data accesscomponent 60, and a report server 170. These components constitute adata masking portal 172 for masking the data while accessing the datasource 100. The architecture, according to various embodiments, canaccommodate a variety of clients: a browser, an application server, aStructure Query Language (SQL) client, a Lightweight Directory AccessProtocol (LDAP) client, a mainframe client (e.g., TN3270 client), aneditor, etc. The data masking operation, in an exemplary embodiment, canbe performed on-the-fly.

Before these clients can access data from the source 100, the end useris authenticated against an enterprise wide authentication system 180,such as Single Sign On (SSO) or Windows Domain system. Based on theauthentication and user configuration policy (resident within the policystore 140), the data masking portal 172 determines whether to mask thedata.

Policies that are created through the configuration wizard 130 arestored in the policy store 140. In general, the policy store 140provides secure storage of sensitive data. The data masking proxy 120will always refers this policy store 140 to mask a given datasource

Under this architecture, the report server 170 provides for logging oftransactions of the portal 172. In an exemplary embodiment, the reportserver 170 creates and stores logs for debugging and tracing purposes.In this manner, graphical reports and text reports can be generatedbased on the transactions. This reporting process can be performed on adaily basis to record information about daily transactions.

The portal 172 can provide either static or dynamic masking. Tode-personalize the data either in static or dynamic mode, varioustechniques can be employed (including, for example, known methods). Incase of static masking of a relational database (for instance), a largenumber of rows are processed, whereas dynamic masking handles a singletable/view or a join of more than one table/view. In this example,de-personalized data can be available in different environments,including production and non-production scenarios. Masking is one of theprocesses for de-personalizing the data by protecting sensitiveinformation in non-production databases from unauthorized visibility.Even though a development team may not require live data, thedevelopment team may need de-personalized/sanitized data for testing ofan application and trouble shooting of particular scenarios or errors ina static mode. Depersonalization (or sanitization) of data poses severalchallenges in testing and production environments.

Data de-personalization/sanitization extends beyond the technicalobstacles. As noted previously, such de-personalization of data ismandated by law. The legal requirements for data sanitization vary fromcountry to country. In the United States for example, theGramm-Leach-Bliley Act requires institutions to protect theconfidentiality and integrity of personal consumer information. TheRight to Financial Privacy Act of 1978 creates statutory FourthAmendment protection for financial records and there are a host ofindividual state laws. There are also a number of security and privacyrequirements for personal information included in the Health InsurancePortability and Accountability Act of 1996 (HIPAA).

With the European Union, Directive 95/46/EC of the European Parliamentprovides strict guidelines regarding individual rights to data privacyand the responsibilities of data holders to guard against misuse. TheUnited Kingdom Data Protection Act of 1998 extends the EuropeanParliament directive and places further statutory obligations on theholders of personal, private or sensitive data.

Thus, any organization that, for example, outsources test anddevelopment operations needs to be conscious of the specific lawsregulating the transmission of information across national borders.However large the legal liabilities associated with such violations are,the costs may be trivial in comparison to the losses associated with thecatastrophic loss of business confidence that is caused by a large scaleprivacy breach.

FIG. 2 is a flowchart of a data masking process, according to variousexemplary embodiments. By way of example, the data masking portal 172performs the data masking process, which is described as follows. Instep 200, the portal 172 detects a request for data, and authenticatesthe end user (step 202). If the determination is in the non-affirmative,per step 203, flow will end here; otherwise, the user configurationpolicy stored in the policy store 140 is retrieved, as in step 204.Based on the user configuration policy and the authentication process,the portal 172 determines, per steps 206 and 208, whether the user hasaccess to this data source. If the user has the proper privilege, theportal 172 can obtain a masking policy and check whether the user hasprivilege to view the real data or masked data, per steps 210 and 212.If the user is not permitted access, the portal 172 can retrieve datacorresponding to the request, and subsequently sending the actual datato the user, as in steps 214 and 216. Next, the transaction is logged bythe report server 170, per step 218.

Returning to step 212 for the determination of whether the masked datais to be viewed, if so, the portal 172 can retrieve the data per step220. In step 222, a masking algorithm is loaded according to the maskingpolicy. The portal 172 then applies the masking algorithm to theretrieved data (step 224). In step 226, the policy is released frommemory. This transaction is then logged by the report server 170, perstep 218. The masked data is then forwarded to the user, as in step 228.

Data masking client components, such as static masking client, SQLclient, LDAP client, Editor, TN3270, web browser, or applications,connect to the data masking proxy 120 for accessing any of theapplications or databases of the data source 100. The data masking proxy120, according to one embodiment, can act as a Windows service, a webservice, or hypertext markup language (HTML) proxy.

FIGS. 3A and 3B are, respectively, a diagram of a masking configurationwizard application of the system of FIG. 1, and a flowchart of policyconfiguration process, according to various exemplary embodiments. Asshown in FIG. 3A, the masking configuration wizard (i.e., configurationengine) 130 permits configuration of each application or database orLDAP. The wizard application 130 steps the user through a series ofinput and selection options to specify the configuration. According toan exemplary embodiment, the masking configuration wizard 130 caninclude an authentication engine 210, an application interface 220, apolicy store interface 230, an algorithm interface 240, and aconfiguration engine 250.

This configuration engine 130 is authenticated against the SSO/Domaininfrastructure 180 so that an authorized user can utilize this wizard130. Once authenticated, the user can be provided with a choice toconfigure a new application or reconfigure existing application, whichwas obtained from the policy store 140. During the configurationprocess, the user can browse available databases through the databaseaccess engine 160 for both data source 100 and data destination 110.Once the database details are obtained from the source database, theuser has option to retrieve an individual table or an individual fieldto perform such legal requirements. Upon selecting the individual tablefrom the database or the parameter from the application, the system canload the algorithms using the algorithm engine 150 for configuration ofthe masking policy for each application or database. Once all requiredparameters or fields required for an application or database areconfigured with the respective algorithm and a salt value (i.e., randomdata) required for the application or field, the configuration engine351 can create an extended mark-up language (XML) policy according toeach application and stored on the policy store 140.

In addition, the user details of those who need the data not to bemasked will be added in the XML policy. In this manner, based on theuser authentication and the “No Mask User list”, the portal 172 candetermine whether the data is to be masked, depending on the policy.

The above operation of the configuration engine is illustrated in FIG.3B. In step 300, the user is authenticated based on the user inputs. Ifthe user is authenticated, per the determination in step 302, the usercan invoke an action, as in step 304; however, if the user is notauthenticated, the process ends.

The process then determines whether the user action corresponds to a NewPolicy or an Existing Policy (step 306). If the user action is a “NewPolicy,” the user can input an identifier or name of the policy orconfiguration, as in step 308. Additionally, the user can input thedetails such as Data Source type, Data source location, accesscredentials to access that data source, salt value per steps 310, 312,and 314. Further, the user can input Destination data source type andlocation as well as access credentials, per steps 316 and 318. In step320, the user selects the required tables to mask. The required columnsand mask algorithm are configured, per step 322.

In step 324, the user can specify “Users,” who can access this datasource and provide privileges to view real data or masked data, per step326. This configuration is then saved to the policy store 140, as instep 328.

Returning to the action determination step 306, if the user action isassociated with an “Existing Policy”—i.e., determined as “Re-ConfigurePolicy”, then the policy is retrieved, per step 330. The user can modifythe source credentials, destination credentials, salt value, per steps332, 334, and 336. At this point, the steps 320-328 are performed forthis Existing Policy, as with the “New Policy” creation.

FIGS. 4A and 4B are, respectively, a diagram of a data masking proxy ofthe system of FIG. 1, and a flowchart of a data masking process,according to an exemplary embodiment. Data masking client components,such as static masking client, SQL client, LDAP client, Editor, TN3270,web browser, or applications, connect to the data masking proxy 120 foraccessing any of the applications or databases of the data source 100.The data masking proxy 120, according to one embodiment, can act as aWindows service, a web service, Telnet Proxy, or hypertext markuplanguage (HTML) proxy.

The data masking proxy 120, in an exemplary embodiment, includes arequest listener 410, an authorization engine 420, a service interfacelistener 430, a masking engine 440, and a response broker 450. Therequest listener 410 listens to requests and classifies the requests toinvoke the respective services for such requests, as illustrated in FIG.6. Based on the request and the user authentication, the authorizationengine 420 authorizes whether the data is to be masked based on the userinformation, as specified in the XML policy.

FIG. 4B describes the workflow of the data masking engine 172. In step401, the portal 172 retrieves data from the corresponding data sourcewith the help of data access components. In step 403, the policy detailsare accessed from the policy store 140. In an exemplary embodiment, datais read row by row, and column by column, per steps 405 and 407; thisreading process continues for all relevant data, which in this exampleis a particular column. At this juncture, the process determines whetherthe data is to be masked according to the configuration policy (steps409, 411). If masking is specified, the required mask algorithm isretrieved and applied to the column of data (step 413); otherwise, theoriginal data is maintained (step 415). In steps 417 and 419, theprocess continues to determine whether masking is to be performed on thedata, by column then row. In step 421, the masked data is provided tothe client (or user).

FIG. 5 is a diagram of a masking algorithm engine of the system of FIG.1, according to an exemplary embodiment. For the purposes ofillustration, the masking algorithm engine 150 support a variety ofmasking schemes 500-555 depending on the privacy data requirements. Thealgorithms 500-555 can accept custom defined salt value as input to therespective algorithm, so that the resultant masked value of the samedata from two different applications can differ. This capabilityenhances the effectiveness of the masking algorithm as well as theapplications. The algorithms can include a Character Mask scheme 500, aCreditCard Mask String and Int64 scheme 505, a PhoneNumber mask stringand Int64 scheme 510, a PrimaryKey Mask Int32 and Int64 scheme 515, aPrimaryKey Mask String scheme 520, a Jumble Mask String scheme 525, anAddressMask scheme 530, an IPAddressMask scheme 535, a NameMask scheme540, a ZipCodeMask scheme 545, a NumberMask scheme 550, and a SSN maskstring and Int64 scheme 555. It is contemplated that the algorithmengine 150 can be updated with other schemes based on the requirements.

The masking proxy, according to one embodiment, is further detailed inFIG. 6. Requests 610 from disparate clients are received by the RequestListener 310. The required number of threads are created by a MaskEngine 620, corresponding with the number of requests 610. For example,if n number of requests are received, the Mask Engine 620 utilizes nnumber of threads. The Mask Engine 620 communicates with the Policystore 140 to obtain the policy bounded for this request. The Mask Engine620 uses the Algorithm Engine 150 to load the necessary algorithm toprocess the masking. The Data Access Engine 160 is used by the MaskEngine 620 to access data from the Data sources 100. The processed datais supplied to the Response broker 350, which then handovers the data asone or more responses 630 to the clients. In this example, n responsesare generated for the n requests.

It is recognized that the data masking requirement for any largeorganization can be rather extensive. These applications can be Staticmasking, SQL Client, LDAP client, HTM Masking, mainframe access client,editor for various documents type and etc. which are presented in otherpatents (refer the previous patents) by the same inventors.

The above described processes relating to data masking may beimplemented via software, hardware (e.g., general processor, DSP chip,an application specific integrated circuit (ASIC), field programmablegate arrays (FPGAs), etc.), firmware, or a combination thereof. Suchexemplary hardware for performing the described functions is detailedbelow.

FIG. 7 illustrates a computer system 700 upon which an embodimentaccording to an exemplary embodiment can be implemented. For example,the processes described herein can be implemented using the computersystem 700. The computer system 700 includes a bus 701 or othercommunication mechanism for communicating information and a processor703 coupled to the bus 701 for processing information. The computersystem 700 also includes main memory 705, such as a random access memory(RAM) or other dynamic storage device, coupled to the bus 701 forstoring information and instructions to be executed by the processor703. Main memory 705 can also be used for storing temporary variables orother intermediate information during execution of instructions by theprocessor 703. The computer system 700 may further include a read onlymemory (ROM) 707 or other static storage device coupled to the bus 701for storing static information and instructions for the processor 703. Astorage device 709, such as a magnetic disk or optical disk, is coupledto the bus 701 for persistently storing information and instructions.

The computer system 700 may be coupled via the bus 701 to a display 711,such as a cathode ray tube (CRT), liquid crystal display, active matrixdisplay, or plasma display, for displaying information to a computeruser. An input device 713, such as a keyboard including alphanumeric andother keys, is coupled to the bus 701 for communicating information andcommand selections to the processor 703. Another type of user inputdevice is a cursor control 715, such as a mouse, a trackball, or cursordirection keys, for communicating direction information and commandselections to the processor 703 and for controlling cursor movement onthe display 711.

According to one embodiment contemplated herein, the processes describedare performed by the computer system 700, in response to the processor703 executing an arrangement of instructions contained in main memory705. Such instructions can be read into main memory 705 from anothercomputer-readable medium, such as the storage device 709. Execution ofthe arrangement of instructions contained in main memory 705 causes theprocessor 703 to perform the process steps described herein. One or moreprocessors in a multi-processing arrangement may also be employed toexecute the instructions contained in main memory 705. In alternativeembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement certain embodiments.Thus, the exemplary embodiments are not limited to any specificcombination of hardware circuitry and software.

The computer system 700 also includes a communication interface 717coupled to bus 701. The communication interface 717 provides a two-waydata communication coupling to a network link 719 connected to a localnetwork 721. For example, the communication interface 717 may be adigital subscriber line (DSL) card or modem, an integrated servicesdigital network (ISDN) card, a cable modem, a telephone modem, or anyother communication interface to provide a data communication connectionto a corresponding type of communication line. As another example,communication interface 717 may be a local area network (LAN) card (e.g.for Ethernet™ or an Asynchronous Transfer Model (ATM) network) toprovide a data communication connection to a compatible LAN. Wirelesslinks can also be implemented. In any such implementation, communicationinterface 717 sends and receives electrical, electromagnetic, or opticalsignals that carry digital data streams representing various types ofinformation. Further, the communication interface 717 can includeperipheral interface devices, such as a Universal Serial Bus (USB)interface, a PCMCIA (Personal Computer Memory Card InternationalAssociation) interface, etc. Although a single communication interface717 is depicted in FIG. 7, multiple communication interfaces can also beemployed.

The network link 719 typically provides data communication through oneor more networks to other data devices. For example, the network link719 may provide a connection through local network 721 to a hostcomputer 723, which has connectivity to a network 725 (e.g. a wide areanetwork (WAN) or the global packet data communication network nowcommonly referred to as the “Internet”) or to data equipment operated bya service provider. The local network 721 and the network 725 both useelectrical, electromagnetic, or optical signals to convey informationand instructions. The signals through the various networks and thesignals on the network link 719 and through the communication interface717, which communicate digital data with the computer system 700, areexemplary forms of carrier waves bearing the information andinstructions.

The computer system 700 can send messages and receive data, includingprogram code, through the network(s), the network link 719, and thecommunication interface 717. In the Internet example, a server (notshown) might transmit requested code belonging to an application programfor implementing an exemplary embodiment through the network 725, thelocal network 721 and the communication interface 717. The processor 703may execute the transmitted code while being received and/or store thecode in the storage device 709, or other non-volatile storage for laterexecution. In this manner, the computer system 700 may obtainapplication code in the form of a carrier wave.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to the processor 703 forexecution. Such a medium may take many forms, including but not limitedto non-volatile media, volatile media, and transmission media.Non-volatile media include, for example, optical or magnetic disks, suchas the storage device 709. Volatile media include dynamic memory, suchas main memory 705. Transmission media include coaxial cables, copperwire and fiber optics, including the wires that comprise the bus 701.Transmission media can also take the form of acoustic, optical, orelectromagnetic waves, such as those generated during radio frequency(RF) and infrared (IR) data communications. Common forms ofcomputer-readable media include, for example, a floppy disk, a flexibledisk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM,CDRW, DVD, any other optical medium, punch cards, paper tape, opticalmark sheets, any other physical medium with patterns of holes or otheroptically recognizable indicia, a RAM, a PROM, and EPROM, a FLASH-EPROM,any other memory chip or cartridge, a carrier wave, or any other mediumfrom which a computer can read.

Various forms of computer-readable media may be involved in providinginstructions to a processor for execution. For example, the instructionsfor carrying out various embodiments may initially be borne on amagnetic disk of a remote computer. In such a scenario, the remotecomputer loads the instructions into main memory and sends theinstructions over a telephone line using a modem. A modem of a localcomputer system receives the data on the telephone line and uses aninfrared transmitter to convert the data to an infrared signal andtransmit the infrared signal to a portable computing device, such as apersonal digital assistant (PDA) or a laptop. An infrared detector onthe portable computing device receives the information and instructionsborne by the infrared signal and places the data on a bus. The busconveys the data to main memory, from which a processor retrieves andexecutes the instructions. The instructions received by main memory canoptionally be stored on storage device either before or after executionby processor.

In the preceding specification, various preferred embodiments have beendescribed with reference to the accompanying drawings. It will, however,be evident that various modifications and changes may be made thereto,and additional embodiments may be implemented, without departing fromthe broader scope of the invention as set forth in the claims that flow.The specification and the drawings are accordingly to be regarded in anillustrative rather than restrictive sense.

The following patent applications are incorporated herein by referencein their entireties: co-pending U.S. patent application (Attorney DocketNo. 20070143) filed ______,_ entitled “Method and Apparatus forProviding a Data Masking Portal”; and co-pending U.S. patent application(Attorney Docket No. 20070312) filed ,entitled “Method and System forMasking Real-time Data.”

1. A method comprising: determining whether an action initiated by anauthenticated user corresponds to one of a plurality of policies storedin a policy store, wherein the policies relate to whether data to beretrieved from a data source is to be masked; generating a new policy ifno match is found in the policy store; receiving information associatedwith the new policy, wherein the information is input by the user; andstoring the new policy in the policy store.
 2. A method as recited inclaim 1, wherein the input information includes an identifier for thenew policy, data source type, data source location, access credentialsfor the data source, salt value for a masking algorithm used to mask thedata, data destination type, data destination location, or accesscredentials for a data destination.
 3. A method as recited in claim 1,wherein the input information further includes user privilegeinformation for viewing the data.
 4. A method as recited in claim 1,wherein the data from the data source is in form of one or more databasetables, the further comprising: receiving selection information aboutthe tables that is to be retrieved from a data source.
 5. A method asrecited in claim 1, wherein the user specifies information about userswho are authorized to access the data.
 6. A method as recited in claim1, further comprising: modifying, if a match is found, the correspondingpolicy based on information supplied by the user.
 7. A systemcomprising: a policy store configured to a plurality of policiesrelating to whether data to be retrieved from a data source is to bemasked; and a data masking proxy configured to access the policy storeand to determine whether an action initiated by an authenticated usercorresponds to one of the stored policies, wherein the data maskingproxy is further configured to generate a new policy if no match isfound in the policy store, the user inputting information associatedwith the new policy, the new policy being stored in the policy store. 8.A system as recited in claim 7, wherein the input information includesan identifier for the new policy, data source type, data sourcelocation, access credentials for the data source, salt value for amasking algorithm used to mask the data, data destination type, datadestination location, or access credentials for a data destination.
 9. Asystem as recited in claim 7, wherein the input information furtherincludes user privilege information for viewing the data.
 10. A systemas recited in claim 7, wherein the data from the data source is in formof one or more database tables, the user specifying selectioninformation about the tables that is to be retrieved from a data source.11. A system as recited in claim 7, wherein the user specifiesinformation about users who are authorized to access the data.
 12. Asystem as recited in claim 7, wherein if a match is found thecorresponding policy is modified based on information supplied by theuser.
 13. A method comprising: receiving a request from an applicationfor retrieval of data; authenticating an end user associated with therequest; determining a service corresponding to the request; masking thedata based on the request and the authentication; and forwarding themasked data to application.
 14. A method as recited in claim 13, whereinthe determination whether to mask the data is further based on policyinformation stored in a policy store, wherein the policy information wascreated in response to input from the end user.
 15. A method as recitedin claim 13, further comprising: generating a thread to process therequest; receiving another request from another application; andgenerating another thread to process the other request.
 16. A method asrecited in claim 13, wherein the data is retrieved from one of aplurality of data sources, and the requests are processed using datafrom different ones of the data sources.
 17. A method as recited inclaim 15, further comprising: outputting a plurality of responsescorresponding to the requests, wherein the responses include respectivemasked data.
 18. A method according to claim 15, wherein theapplications include anyone or more of a Structure Query Language (SQL)application, a Lightweight Directory Access Protocol (LDAP), or aHyperText Markup Language (HTML) application.
 19. A system comprising: arequest listener configured to receive a request from an application forretrieval of data; an authorization engine configured to authenticate anend user associated with the request; a service interface listenerconfigured to determine a service corresponding to the request; amasking engine configured to mask the data, using a masking algorithm,based on the request and the authentication; and a response brokerconfigured to forward the masked data to application.
 20. A system asrecited in claim 19, wherein the determination whether to mask the datais further based on policy information stored in a policy store, whereinthe policy information was created in response to input from the enduser.
 21. A system as recited in claim 19, wherein the request listenerreceives a plurality of requests from a plurality of applications, thesystem further comprising: a mask engine configured to generate aplurality of threads configured to process the requests.
 22. A system asrecited in claim 21, further comprising: a data access engine configuredto communicate with a plurality of data sources, wherein the data isretrieved from one of the data sources, and the requests are processedusing data from different ones of the data sources.
 23. A system asrecited in claim 21, wherein the response broker is further configuredto output a plurality of responses corresponding to the requests,wherein the responses include respective masked data.
 24. A systemaccording to claim 21, wherein the applications include anyone or moreof a Structure Query Language (SQL) application, a Lightweight DirectoryAccess Protocol (LDAP), or a HyperText Markup Language (HTML)application.